技术负责人

会聊一聊技术格局、视野、人生规划、软技能考察，这部分多展示你的大局观，比如业务上的大图，技术上的大图，你长期或短期的人生规划等等。

你在做什么？

可以先描述一下自己的能力与岗位要求的契合度，表现出在公司提供的岗位上有机会可以一展所长；
1. 需要表现出对应聘岗位和企业的认同感，也让面试官看到你为了这份工作做了很充分的准备，或者积极的介绍之前做过的项目与应聘企业项目的相似度。这些表现都可以让面试官感受到你的热情和积极正向的输出
2. 因为目前这份工作和我之前做过的 xxx 项目非常相像。我在参与上一份项目时学习到了 xxx 技能，找到了一个新的发展方向，从而喜欢上了这样的一份职业。
3. 在前司获得的成长有哪些，与前 leader 的身上都学习到了哪些工作思路和成长思路等
说出几个被企业所吸引的优点，这些优点能为以后的工作带来什么好处；
1. 例如业界口碑挺好，技术氛围不错。
自己的职业发展与公司前景作出总结。
1. 职业发展到现在，我觉得已经进入深耕期，也希望找一个实力更强的团队，有更好的机会，以后也希望走 TL 的路线，虽然离我也比较远。
2. 我对自己的定位是走技术架构师的路线的，但同时我会希望自己所专业的领域的业务是好落地的。
3. 前端团队主导，更有话语权。

切忌抱怨，不要吐槽，更不要说和现在领导不和睦之类的话。多从自身发展找原因，可以表达寻找自己心目中的好的技术团队氛围和平台机会。

eslint + 工具，规范代码格式，以及 commit message lint 提交规范
接入代码扫描，能扫除一些常见的安全漏洞和由代码书写不规范造成的安全问题，比如没有 encode/decode url 中的参数等；直接 replace 或者将 hash 值更新到 url 中
合入发布分支之前做 code view
ci 执行代码规范之前，也需要做单元测试。
针对咱们 low code 的场景，一般会考虑用到定时任务 mock 用户去请求接口，跟上一次结果做对比，检查 node 的正常与否。同时这样也能够对数据做预缓存。如果条件允许的话，一般也是要做 ui 的自动化测试的。
代码级别的限频？等
代码中禁止写入 ip，密码等隐私信息
sourcemap 发布 cdn 之前需要删除
做好监控和告警
做好代码规范、前端安全等分享

发布分支与环境绑定，合并代码到发布分支需要经过 code review
ci 在 pr 发起时会检查 eslint 的规范，code review 时在检查一遍被 ignore 掉的一些代码。如果不规范，则打回不予发布测试、预发环境。
规范建立：
1. 首先总结当前项目汇总使用最多的 eslint 包是什么，结合业界最受环境的 config（当时选用了 alloy team 的 config）创建了一个 repo 仓库，首先在自己的项目中实验，配好 fix/lint 两种级别模式。
2. 一般还包括 editorConfig 和 prettierConfig 都定义好，跟 eslintrc 写好每一项的注释。
3. 如果有新的规则，在 issue 中进行讨论，大多数人同意之后，由发起 issue 的人，提交一个 pr 到 master 分支中，最后大家在各自项目中更新版本。